Cryptext x64 File Format v1 -- DRAFT 0.1
========================================

STATUS
------
This is deliberately NOT frozen yet. Source 0.1 contains no active writer.
Once test vectors exist, changes that would break decryption require a new
format version rather than silently changing v1.

Goals
-----
* AES-256-GCM using Windows CNG.
* PBKDF2-HMAC-SHA-256 using Windows CNG for the CNG-only v1 implementation.
* One random 16-byte salt per file.
* One random 8-byte nonce prefix per file.
* Independent authenticated records, default 4 MiB data chunks.
* Nonce = 8-byte random prefix || 32-bit big-endian record index.
* Record 0 is encrypted metadata. Data records begin at index 1.
* 16-byte GCM tag per record.
* The fixed header and per-record index/length are AAD.
* Password text encoding is still to be frozen before writer activation.

Filename convention
-------------------
plain:      example.pdf
encrypted:  example.pdf.$#!
in progress example.pdf.$#!.temp   (normally FILE_ATTRIBUTE_HIDDEN)

Transactional write rule
------------------------
The plaintext source is never modified in place. A complete authenticated
output is written and flushed first. Only after successful finalization is the
original optionally removed.

Alternate temporary volume
--------------------------
The normal temporary file is beside the source on the same volume. If there is
not enough free space, Cryptext informs the user. An alternate %TEMP% volume is
only an explicit fallback if it is actually on a different volume and has
sufficient space. Cryptext never silently stages sensitive files elsewhere.

Metadata
--------
The encrypted metadata record is planned to contain at least:
* original creation time
* original last-write time
* original last-access time (subject to final policy)
* restorable FILE_ATTRIBUTE_* subset
* future metadata version/length fields

Zone.Identifier
---------------
The NTFS Zone.Identifier alternate data stream (Mark-of-the-Web) is explicitly
NOT preserved or restored. This is a deliberate product policy.

Other ADS
---------
Other NTFS alternate data streams are not promised by source 0.1. If/when ADS
preservation is enabled, it must be versioned and authenticated. No UI or code
may claim lossless ADS preservation before that implementation exists.

Recovery compatibility
----------------------
CryptextDecrypt.exe must require no shell extension, registry vault, DPAPI vault
state or installation metadata. It will read published historical format
versions and the actual long password is sufficient to recover a file.

Legacy Cryptext 3.4
-------------------
A separate read-only compatibility decoder is planned. Legacy RC4/SHA-1 will
never be used to create new files.
